There are many types of computing services, resources and data that computer users and applications need to manage and otherwise access. Such resources and data include services and data maintained locally, and data maintained on corporate networks and other remotely accessible sites including intranets and the internet.
The concept of web services is generally directed to providing a computing service to clients via protocols and standards that are cross-platform in nature. In general, web services provides the basic tools for wiring the nodes of a distributed application together regardless of the type of platform on which the requesting client is running. As there are many different computing platforms, various platform-independent mechanisms and protocols that facilitate the exchange of network information are becoming commonplace in web services, including HTTP (HyperText Transfer Protocol), XML (extensible Markup Language), XML Schema, and SOAP (Simple Object Access Protocol) XML. Traditional web services, in which businesses, organizations, and other providers offer services to users and applications, are presently based on these standards. Moreover, as described in U.S. patent application Ser. No. 10/328,714, assigned to the assignee of the present invention, a web service can represent other types of resources, such as hardware devices, databases and the like.
Currently, the protocols by which web services exchange data with a client allow a client to send a message to a server port (e.g., URI) corresponding to the service and receive a message back at the client, in a manner agreed on according to a contract provided by the web service. However, one potential problem is that the client needs to send its messages through the service's URI, even though the service itself may be built from separate entities, whereby communication through the service's URI becomes a potential bottleneck.
Another problem with existing protocols is that any given message is not observable without intimate knowledge of the message format, except to basically note that the message exists. As a result, there is no way for an intermediary (e.g., another trusted service) to provide value to the message exchange, because the intermediary cannot be certain of the basic characteristics and/or purpose of the message.
What is needed is a mechanism by which clients and web services can securely and efficiently communicate with a web service, including the entities that make up a service, let allow intermediaries to add value to the communication.